Audit before: 27 dependabot alerts (1 critical, 8 high, 17 moderate, 1 low) /
14 npm audit findings across five root-cause packages. After:
0 vulnerabilities reported by either tool.

Resolution path, in order of leverage:

- Drop @langchain/community. It was never imported. Removing it kills
  the entire @langchain/community → ibm-cloud-sdk-core → axios chain (11
  axios CVEs, follow-redirects header leak, and a stagehand-pulled ws
  instance), along with a transitive langsmith copy.

- Replace @xenova/transformers (2.17.2, abandoned at this version) with
  @huggingface/transformers (4.2.0, the maintained successor). xenova
  pinned onnxruntime-web@1.14.0 which pinned onnx-proto@4.0.4 which
  pinned protobufjs@6.11.4 — vulnerable to a CVSS-9.8 RCE plus eight
  other advisories with no upstream fix coming. The HF package ships
  onnxruntime-web@1.26.x and modern protobuf handling, and its
  pipeline() / FeatureExtractionPipeline surface is signature-identical
  to xenova. Migration is a single import line; runtime contract for
  LocalTransformersEmbeddings is unchanged.

- Bump direct uuid to ^13.0.2 to clear the buffer-bounds advisory on
  v3/v5/v6 — we use uuidv5 for both chunk IDs and Qdrant point IDs, so
  this is on the hot path.

- Pin transitive uuid, langsmith, and ws via npm overrides so the
  fixes hold even when @langchain/core or openai resolves to older
  ranges of those packages.

Verification deferred to runtime:
The HF transformers swap changes the ONNX execution path. Embedding
vectors should be byte-equivalent against the same Xenova/all-MiniLM-L6-v2
model but this hasn't been smoke-tested end-to-end. If output shifts,
the existing Qdrant collection's points become unreachable to new
queries — drop and re-ingest after merge.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Four findings from validating the v0.21.0 doc bump against an actual
ROCm 7.2.1 / gfx1100 host today, each of which would have saved an
hour or so if the doc had covered it:

- Flip the default torch nightly index from rocm6.4 → rocm7.2. The
  rocm7.2 index is now published; the older rocm6.4 wheels carry a
  HIP ABI that doesn't match /opt/rocm 7.2 and produce
  `undefined symbol: _ZN3c10*` at runtime when vLLM's compiled
  extensions try to load against the mismatched libtorch.

- Add CMAKE_ARGS="-DHIP_FOUND=TRUE" to the build env. The rocm7.2
  nightly torch's bundled LoadHIP.cmake detects HIP correctly and
  prints every ROCm library version but no longer exports the
  HIP_FOUND global variable that vLLM's CMakeLists.txt:151 checks.
  Without the override the build dies with "Can't find CUDA or HIP
  installation" despite HIP being clearly present in the configure
  log.

- Add a `python -c "import vllm._C, vllm._rocm_C"` smoke immediately
  after the build. Necessary because opt-125m's code path uses Python
  fallbacks and will load + generate even with stale/broken .so files
  — making the existing smoke test a false-positive on a real ABI
  problem. The Llama-architecture model is the first thing that
  exercises kernels registered by _C.

- Restructure §8 into two stages: opt-125m for build sanity, then
  Llama-3.1-8B for kernel sanity. Update the "expected log lines"
  prefix to the new v0.21.0 TURBOQUANT-rejection wording, document
  the harmless first-request Triton JIT-compile warnings introduced
  by the new jit_monitor, and flag the "Cannot use ROCm custom paged
  attention kernel, falling back to Triton" line as expected on RDNA3
  (it's a fallback *within* ROCM_ATTN, not a fallback *from* it).

Troubleshooting table gains rows for: the HIP_FOUND CMake error, the
torch-ABI undefined-symbol case, the opt-125m false-pass scenario,
the JIT-monitor warnings, and the paged-attention Triton fallback.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>